Frequently Asked Questions

We plan the IMO, Reefer, OOG, restows, expected and stopped containers manually and lock them afterwards. Does this affect the way AutoStow works?

This approach does not affect the way AutoStow works. However, all containers that were previously planned to the vessel are ignored during subsequent AutoStow runs with respect to the position they are being pulled from within the yard.

Is the sequence of events for the depth and width, as described in the manual, followed for every single projection?

Yes, the sequence applies to every uncovered projection that is assessed for container stowage.

We plan to-come containers manually. Would it be a good idea to set the to-come parameter to N, so an error message appears whenever we forget to plan one or more stopped containers manually?

Yes, that might be the best way to handle stopped containers. Otherwise, AutoStow plans them automatically. AutoStow applies a huge penalty to stopped and to-come containers so that they are most likely stowed close to the end of the crane working program.

Is there a way to avoid weight classes in the stow factor and influence weight distribution using AutoStow?

Currently, you can manage weight distribution on a vessel using one of the following methods:

AutoStow does not consider weights defined in the MOVINS file.

Is it possible to influence door direction using AutoStow? We would like to plan the first container in the yard stack on the Aft bay and the second on the Fore bay.

Planning Aft bay first:

You can plan to the Aft bay first using one of the following options:

Defining door direction:

You can do this using the door direction attribute. Click Planning>Set Doors and select the required option. Then include this attribute in the CHE operator screen giving the driver an indication on the desired door direction required at the quayside.

You can also set the default door direction for a vessel bay within a ship file.

Can the number of rehandles generated by AutoStow differ during planning/evaluation?

There should not be any difference in the number of rehandles generated by AutoStow during planning or evaluation, assuming that:

Switching AutoStow strategies may result in different penalty point totals and a different number of penalty occurrences for certain penalties but will not affect the number of rehandles, because a rehandle is not dependent on a strategy setting. A rehandle is counted if there are containers in the yard stack above the candidate container at the time the work instruction is executed. For AutoStow (both planning and evaluation), containers that will not be loaded onto the same outgoing vessel are ignored. The expectation is that every load list container must be moved, so it doesn't really matter if there are several unrelated boxes on top of it or not, at least in relation to any other container that will be outgoing on the same vessel. What the rehandle penalty attempts to minimize is shuffling of containers that are going out on the same vessel - any rehandle counted equals a container that must be lifted more than once, which is wasteful.

However, you may see a difference in the rehandles generated by AutoStow during planning or evaluation in the following scenarios:

During evaluation, existing work instructions are marked "rewound" before the scoring begins. In a client/server operation, this requires an update to be sent to the server, and if that update fails then the evaluation may not generate identical results. Similarly, both planning and evaluation make use of structures outside of the AutoStow code - work queues, crane status and capabilities, etc. If any of these are changed, rehandle counts between planning and evaluation may differ, but these are extremely unlikely scenarios.